Numara Configuration Management

What is Configuration Management?

The Information Technology Infrastructure (ITIL) standards include two main categories for organizing best practices that are further divided into five sub-categories each. One of these requirements is Configuration Management, which is a sub-category of the Services Support category.

Configuration Management deals with tracking individual “Configuration Items" (CIs) throughout an enterprise. Configuration Management involves relating assets or CIs and establishing dependencies and hierarchies. It also involves designating certain services as CIs, such as Email, Internet, etc., and then determining upon which CIs each service is dependent. This process is very important for identifying the impact of any changes that would be made within an organization.

Asset Management and Configuration Management

There is some overlap between Asset Management and Configuration Management in that you can use the assets in your Asset Management database to populate the CIs of your Configuration Management Database (CMDB). However, one of the main features that distinguishes a CMDB from an asset database is relationships. A CMDB allows you to define and manage how CIs are related to one another.

Terms 

You should be familiar with the following terms as they apply to Configuration Management:

• Configuration Management Database (CMDB)—A database used to store Configuration Records throughout their Lifecycle. The Configuration Management System maintains one or more CMDBs, and each CMDB stores Attributes of CIs, and Relationships with other CIs.*
• Configuration Item (CI)—Any Component that needs to be managed in order to deliver an IT Service. Information about each CI is recorded in a Configuration Record within the Configuration Management System and is maintained throughout its Lifecycle by Configuration Management. CIs are under the control of Change Management. CIs typically include IT Services, hardware, software, buildings, people, and formal documentation such as Process documentation and SLAs.*
• Configuration Type (CI Type)—A category for CIs. For example, you might create a configuration type called "Server" in the CMDB.
• Attribute—A piece of information about a Configuration Item. Examples are name, location, Version number, and Cost. Attributes of CIs are recorded in the Configuration Management Database (CMDB).*
• Relationship—A connection or interaction between two people or things. In Configuration Management it is a link between two Configuration Items that identifies a dependency or connection between them. For example Applications may be linked to the Servers they run on; IT Services have many links to all the CIs that contribute to them.*
• Visualization—A figure representing a relationship or relationships. FootPrints Configuration Management uses Java to "draw" a visualization of a CI's relationship(s) dynamically.
• Status—Status is often a required field in many types of Record. It shows the current stage in the Lifecycle of the associated Configuration Item, Incident, Problem, etc.*

* ITIL® V3 Glossary v3.1.24, 11 May 2007. The definition is reproduced with permission.

Planning a Configuration Management Database

The following is a brief description of the steps to take when planning a CMDB using FootPrints Configuration Management:

1. Determine the items you wish to record and manage. Will it be hardware only? Hardware and software? Hardware, software, documentation, databases, and services? Office space? Furniture? Trucks and cars? Cell phones? Because of the flexibility of the FootPrints CMDB, it is possible to create a configuration that can track all of these items and many others. It's up to your decision-makers to determine what to include and what to exclude. A true CMDB should consist of all items IT is responsible for, to assist the business of the company. Great thought should be put into deciding how these items will be related to one another.
2. Create a new CMDB in FootPrints. You can use one of the built-in templates or copy an existing CMDB configuration, if it closely matches your needs. Keep in mind that you can easily modify your configuration after its initial creation. Alternatively, you can build your configuration from scratch, defining all the types, attributes, and relationships on your own. The ITSM project template creates Incident, Problem and Change Management projects integrated into a centralized CMDB.
3. Define the types of CIs that were decided upon in step 1. These can be hardware items, like routers, PCs, servers, FAX machines, printers, and cell phones. These can be software items, like applications. These can be locations, like room numbers. Most of these should be defined already if you used a template or an existing configuration when creating the CMDB.
4. Define attributes for the CI types in the database. Some examples might include Memory, IP Address, Operating System, and Purchase Price for a desktop; Manufacturer, Version Number, and Maintenance Expiration Date for an application; and Manufacturer, Model, and IP Address for a network printer. If a template was used for creating the CMDB, the attributes that came with it should be reviewed and modified to meet your needs.
5. Decide on statuses for your CI types. This will show at a quick glance if, for example, a desktop is in service on someone’s desk (Active), on the shelf ready to be used (In Inventory), or retired waiting to be used for parts (Retired). Different CI types can share the same status or use different statuses. An application, for example, will never be “Waiting for Parts” and a Printer will never be “Under Development”.
6. Define your relationships. If you used a template, there will already be relationships and relationship constraints defined. Make sure they align with your goals and desired functionality. Examples of types of relationships are “Prints To”, “Backs Up”, and “Is Connected to”. The constraints prevent prevent you from relating items that should not be related to one another. For example, a Router should never “Print To” a Switch.
7. Decide on a CI ID format. This will represent the CI on all listings of CIs and all pages that refer to that CI. It should provide enough information to allow someone to identify the CI just by seeing the name. An example format would be “%%CI_TYPE_NAME%%-%%MANUFACTURER%%-%%MODEL%%”, which might display as “Desktop-Dell-Dimension 2400” or “Printer-HP-LaserJet 4100”.
8. Set up imports from your data sources to populate your CMDB. To collect your data, you may be using Numara Asset Manager (NAM), the database of some other asset tool, a database you constructed yourself, an Excel file, or any combination of one or more of these sources. You may also manually create your CIs, although this could be time-consuming.
9. If your import was from NAM, you were able to import the CI relationships as well. They should be reviewed and updated. If you imported from a source other than NAM, you will have to implement all the relationships between the CIs that were imported.
10. Link CIs to Address Book contacts. This could include the main user of that CI, various users of the same CI, or a Service Desk person responsible for that CI.
11. If you plan to continue importing data from external sources, you should decide on an update schedule for imports and configure it appropriately.
12. Add additional settings. These may include such things as creating reports, setting up Automations, and establishing Roles.
13. Before putting your CMDB into production, it is recommended that you test the workflow of how your agents will use the CMDB in working with issues.